Modularity: G: Interoperability and Composition of DSLs with Melange

Domain-Specific Languages (DSLs) are now developed for a wide variety of domains to address specific concerns in the development of complex systems. However, DSLs and their tooling still suffer from substantial development costs which hamper their successful adoption in the industry. For over a decade, researchers and practitioners have developed language workbenches with the promise to ease the development of DSLs. Despite many advances, there is still little support for advanced scenarios such as language evolution, composition, and interoperability. In this paper, we present a modular approach for assembling DSLs from other ones and seamlessly evolving them, while ensuring the reuse of associated tools through subsequent versions or across similar DSLs. We introduce the theoretical foundations of our approach, its implementation in the Melange language workbench, and summarize its benefits on various case studies. 1. Problem and Motivation The development of complex software-intensive systems involves many stakeholders who bring their expertise on specific concerns of the developed system. Model-Driven Engineering (MDE) proposes to address each concern separately with a dedicated Domain-Specific Language (DSL) closely linked to the needs of each stakeholder [15]. With DSLs, stakeholders express their models in terms of problemlevel abstractions. Associated tools are then used to semiautomatically transform the models into concrete software artifacts. Amongst the different kinds of DSLs (internal, embedded, external), external DSLs offer the best flexibility [12]. However, the definition of an external DSL (syntax and semantics) and its environment (e.g. checkers, editors, generators, IDEs) still requires substantial development efforts for, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. CONF ’yy, Month d–d, 20yy, City, ST, Country. Copyright c © 20yy ACM 978-1-nnnn-nnnn-n/yy/mm. . . $15.00. http://dx.doi.org/10.1145/nnnnnnn.nnnnnnn by definition, a limited audience. The Software Language Engineering community thus focuses on the development of tools and methods that ease the development of DSLs. Although DSLs are by definition tied to a particular domain, one can see the emergence of recurrent paradigms shared by various DSLs used in different areas. Finite-state machine (FSM) languages, for instance, are used in many distinct contexts (e.g. language processing, user interfaces, systems and software engineering). While variants of FSM languages share many common concepts, they also exhibit syntactic and semantic variation points imposed by the specificities of the domain [6]. Redefining from scratch a new FSM language for each new domain contrasts with the good practices established in software engineering. Instead, language workbenches should provide language designers with the ability to import existing DSL specifications, customize and compose them to build new ones for other domains. Another recurring problem in DSL development results from the fact that the tooling defined around a given language is highly coupled with it. Therefore, DSLs are extremely fragile to evolution: when a DSL evolves, its environment (e.g., IDE) and the models created from it must be updated consequently. As DSLs evolve at a rather fast pace, this has severe consequences. The coupling between DSLs and their tooling also prevents the manipulation of models in different modeling environments. It is for instance not possible to share the same model between two FSM modeling environment (e.g. used by two different stakeholders), even when they share a lot of commonalities. This lack of flexibility and interoperability makes the work of language users difficult, as they cannot benefit from tools defined for different yet similar DSLs. In this paper, we identify that this lack of flexibility arises from the theoretical foundations of MDE. To circumvent these limitations, we propose the notion of language interface that we use to design composition operators that ease the work of language designers, and to design a dedicated type system that provides more flexibility in model manipulation to DSL users. The remainder of this paper is organized as follows. Section 2 gives some background notions and an overview of the related work. Section 3 details our approach. Section 4 presents the Melange language workbench and the results we gathered through its application to various case studies. 2. Background and Related Work DSLs are typically defined through three main concerns: abstract syntax, concrete syntax(es) and semantics. Various approaches may be employed to specify each of them, usually using dedicated meta-languages [34]. The abstract syntax specifies the domain concepts and their relations and is defined by a metamodel or a grammar. This choice often depends on the language designer’s background and culture. Examples of meta-languages for specifying the abstract syntax of a DSL include EMOF [1] and SDF [17]. The semantics of a DSL can be defined using axiomatic semantics, denotational semantics, operational semantics, and their variants [26]. Concrete syntaxes are usually specified as a mapping from the abstract syntax to textual or graphical representations, e.g. through the definition of a parser or a projectional editor [36]. In this paper, we focus on DSLs whose abstract syntaxes are defined with metamodels and whose semantics are defined in an operational way through the definition of computational steps designed following the interpreter pattern. Computational steps may be defined in different ways, e.g. using aspect-oriented modeling [18] or endogenous transformations. In this paper, however, we only focus on the weaving of computational steps in an object-oriented (OO) fashion with the interpreter pattern. In such a case, specifying the operational semantics of a DSL involves the use of an action language to define methods that are statically introduced directly in the corresponding concepts of its abstract syntax [19]. 2.1 Modular Development of DSLs Recent work in the community of Software Language Engineering focused on language workbenches that support the modular design of DSLs, and the possible reuse of such modules [21, 32]. Besides, particular composition operators have been proposed for unifying or extending existing languages [11, 24]. Other techniques have been studied for addressing the challenge of language extension and composition, such as projectional editing [35] or composable meta-languages [37]. Other authors demonstrated the possibility to create language modules using attribute grammars [20, 25, 29]. MontiCore applied modularity concepts for designing new DSLs by extending an existing one, or by composing other DSLs [22]. Finally, some works propose to leverage concepts from the component-based software engineering community to modularly develop DSLs [32, 38]. However, while most of the approaches propose either a diffuse way to reuse language modules, or to reuse as is complete languages, there is still little support for easily assembling language modules with customization facilities (e.g. restriction, specialization) in order to finely tune the resulting DSL according to the language designer’s requirements. 2.2 Model Transformation Reuse To ease the use of a DSL by stakeholders, language designers usually develop an associated modeling environment with dedicated editors, simulators, transformations, generators, etc.. Typically, these different tools are model transformations that manipulate the models conforming to a given DSL. To state whether a model conforms to a given DSL, MDE relies on the conformance relation that stands between a model and its metamodel [2, 3, 14]. The conformance relation plays a crucial role in MDE as it identifies which models are valid instances of a given DSL and how they should be safely manipulated. A fundamental property of the conformance relation is that a model conforms to one, and only one, metamodel. Therefore, when the metamodel defining the abstract syntax of a DSL evolves, the models no longer conform to it. As a consequence, all the tools and transformations defined around it must be updated. The research community has identified this problem of transformation reuse and proposed techniques to design generic model transformations. Varró and Pataricza introduced variable entities in patterns for declarative transformation rules [33]. Later, Cuccuru et al. introduced the notion of semantic variation points in metamodels [7]. Sánchez Cuadrado and García Molina propose a notion of substitutability based on model typing and model type matching [28]. De Lara and Guerra present the concept mechanism, along with model templates and mixin layers [8]. However, all these approaches require either to design metamodels and transformations in a special way, or to explicitly write the bindings between similar DSLs. As we shall see in the next section, our approach does not require any additional work from the language designer or user when the languages are similar enough, such as different versions or variants of a DSL. 3. Approach and Uniqueness We structure our approach around two interconnected contributions: a dedicated type system for language interoperability and an algebra of operators for language composition. These two contributions rely on a common core concept of language interface. The operators and relations discussed in this section are summarized in Figure 1. Language interfaces allow to abstract some of the intrinsic complexity carried in the implementation of languages, by exposing meaningful information (i) concerning an aspect of a language (e.g. syntactical constructs) (ii) for a specific purpose (e.g. composition, reuse, coordination) (iii) in an appropriate formalism (e.g. a metamodel). In this regard, language interfaces can be thought of as a reasoning layer atop language implementations. The definition of language interfaces relies on proper formalisms for expressing different kinds of interfaces and binding relations between language implementations and interfaces. Interfaces may be manually crafted (thereby defining a contract) or automatically inferred from an existing language. Using language interfaces, one